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Abstract. We propose a novel, comonadic approach to dataflow (stream- 
based) computation. This is based on the observation that both general 
and causal stream functions can be characterized as coKleisli arrows of 
comonads and on the intuition that comonads in general must be a good 
means to structure context-dependent computation. In particular, we de¬ 
velop a generic comonadic interpreter of languages for context-dependent 
computation and instantiate it for stream-based computation. We also 
discuss distributive laws of a comonad over a monad as a means to struc¬ 
ture combinations of effectful and context-dependent computation. 
We apply the latter to analyse clocked dataflow (partial stream based) 
computation. 


1 Introduction 

Shall we be pure or impure? Today we shall be very pure. It must always be pos¬ 
sible to contain impurities (i.e., non-functionalities), in a pure (i.e., functional) 
way. 

The program 

fact x = if x <= 1 then 1 else fact (x - 1) * x 

for factorial encodes a pure function. 

The programs 

factM x = (if x == 5 then raise else 

if x <= 1 then 1 else factM (x - 1) * x) 

‘handle 1 (if x == 7 then 5040 else raise) 


and 

factL x = if x <= 1 then 1 else factL (x - 1) * (1 ‘choice' x) 

represent “lossy” versions of the factorial function. The first yields an error on 
5 and 6 whereas the second can fail to do some of the multiplications required 
for the normal factorial. These impure “functions” can be made sense of in the 
paradigms of error raising/handling and non-deterministic computations. Ever 
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since the work by Moggi and Wadler [26140141] . we know how to reduce impure 
computations with errors and non-determinism to purely functional computa¬ 
tions in a structured fashion using the maybe and list monads. We also know how 
to explain other types of effect, such as continuations, state, even input/output, 
using monads! 

But what is more unnatural or hard about the following program? 

pos = 0 fby (pos + 1) 

fact = 1 fby (fact * (pos +1)) 

This represents a dataflow computation which produces two discrete-time signals 
or streams: the enumeration of the naturals and the graph of the factorial func¬ 
tion. The syntax is essentially that of Lucid [2] , which is an old intensional lan¬ 
guage, or Lustre m or Lucid Synchrone PUSH, the newer French synchronous 
dataflow languages, fby reads ‘followed by’ and means initialized unit delay of a 
discrete-time signal (cons of a stream). 

Could it be that monads are capable of structuring notions of dataflow com¬ 
putation as well? No, there are simple reasons why this must be impossible. (We 
will discuss these.) As a substitute for monads, Hughes has therefore proposed 
a laxer framework that he has termed arrow types m (and Power et al. [52] 
proposed the same under the name of Freyd categories). But this is—we assert— 
overkill, at least as long as we are interested in dataflow computation. It turns 
out that something simpler and more standard, namely comonads, the dual of 
monads, does just as well. In fact, comonads are even better, as there is more 
structure to comonads than to arrow types. Arrow types are too general. 

The message of this paper is just this last point: While notions of dataflow 
computation cannot be structured with monads, they can be structured perfectly 
with comonads. And more generally, comonads have received too little attention 
in programming language semantics compared to monads. Just as monads are 
good for speaking and reasoning about notions of functions that produce effects, 
comonads can handle context-dependent functions and are hence highly relevant. 
This has been suggested earlier, e.g., by Brookes and Geva [5] and Kieburtz 123], 
but never caught on because of a lack of compelling examples. But now dataflow 
computation provides clear examples and it hints at a direction in which there 
are more. 

The paper contributes a novel approach to dataflow computation based on 
comonads. We show that general and causal stream functions, the basic entities 
in intensional resp. synchronous dataflow computation, are elegantly described 
in terms of comonads. Imitating monadic interpretation, we develop a generic 
comonadic interpreter. By instantiation, we obtain interpreters of a Lucid-like 
intensional language and a Lucid Synchrone-like synchronous dataflow language. 
Remarkably, we get elegant higher-order language designs with almost no effort 
whereas the traditional dataflow languages are first-order and the question of 
the meaningfulness or right meaning of higher-order dataflow has been seen 
as controversial. We also show that clocked dataflow (i.e., partial-stream based 
computation) can be handled by distributive laws of the comonads for stream 
functions over the maybe monad. 
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The organization of the paper is as follows. In Section 0 we give a short 
introduction to dataflow programming. In Section [31 we give a brief review of 
the Moggi-Wadler monad-based approach to programming with effect-producing 
functions in a pure language and to the semantics of corresponding impure lan¬ 
guages. In particular, we recall monadic interpretation. In Section 0 we show 
that certain paradigms of computation, notably stream functions, do not fit 
into this framework, and introduce the substitute idea of arrow types/Freyd 
categories. In Section 0 we introduce comonads and argue that they struc¬ 
ture computation with context-dependent functions. We show that both general 
and causal stream functions are smoothly described by comonads and develop 
a comonadic interpreter capable of handling dataflow languages. In Section 0 
we show how effects and context-dependence can be combined in the presence 
of a distributive law of the comonad over the monad, show how this applies 
to partial-stream functions and present a distributivity-based interpreter which 
copes with clocked dataflow languages. Section 0 is a summary of related work, 
while Section [5] lists our conclusions. 

We assume that the reader is familiar with the basics of functional program¬ 
ming (in particular, Haskell programming) and denotational semantics and also 
knows about the Lambek-Lawvere correspondence between typed lambda calculi 
and cartesian closed categories (the types-as-objects, terms-as-morphisms corre¬ 
spondence). The paper contains a brief introduction to dataflow programming, 
but acquaintance with languages such as Lucid and Lustre or Lucid Synchrone 
will be of additional help. Concepts such as monads, comonads etc. are defined 
in the paper. 

The paper is related to our earlier paper m, which discussed comonad- 
based dataflow programming, but did not treat comonad-based processing of 
dataflow languages. A short version of the present paper (without introductions 
to dataflow languages, monads, monadic interpretation and arrows) appeared 
as [35] , 


2 Dataflow Programming 

We begin with an informal quick introduction to dataflow programming as sup¬ 
ported by languages of the Lucid family [2] and the Lustre and Lucid Synchrone 
languages [111131] . We demonstrate a neutral syntax which we will use throughout 
the paper. 

Dataflow programming is about programming with streams, thought about 
as signals in discrete time. The style of programming is functional, but any 
expression denotes a stream (a signal), or more exactly, the element of a stream 
at an understood position (the value of a signal the time instant understood as 
the present). Since the position is not mentioned, the stream is defined uniformly 
across all of its positions. Compare this to physics, where many quantities vary 
in time, but the time argument is always kept implicit and there is never any 
explicit dependency on its value. 
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All standard operations on basic types are understood pointwise (so in par¬ 
ticular constants become constant streams). The if-construct is also understood 
pointwise. 


X 

Xo 

Xi 

X2 X3 

X4 

xs 

y 

yo 

2/i 

2/2 2/3 

2/4 

2/5 

x + y 

xo + yo 

*i + yi 

X2 +2/2 X 3 + 2/3 

X4 + 1/4 

*5+2/5 ■ ■ ■ 

z 

t 

f 

t t 

/ 

t 

if z then x else y 

Xo 

2/i 

X‘2 X3 

2/4 

X 5 


If we had product types, the projections and the pairing construct would also 
be pointwise. With function spaces, it is not obvious what the design should 
be and we will not discuss any options at this stage. As a matter of fact, most 
dataflow languages are first-order: expressions with variables are of course al¬ 
lowed, but there are no first-class functions. 

With the pointwise machinery, the current value of an expression is always 
determined by the current values of its variables. This is not really interesting. 
We should at least allow dependencies on the past values of the variables. This is 
offered by a construct known as fby (pronounced “followed by”). The expression 
eO fby el takes the initial value of eO at the beginning of the history, and at 
every other instant of time it takes the value that el had at the immediately 
preceding instant. In other words, the signal eO fby el is the unit delay of the 
signal el, initialized with the initial value of eO. 


X 
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Xi 
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With the fby operator, one can write many useful recursive definitions where 
the recursive calls are guarded by fby and there is no real circularity. Below are 
some classic examples of such feedback through a delay. 

pos = 0 fby pos + 1 

sum x = x + (0 fby sum x) 

diff x = x - (0 fby x) 

ini x = x fby ini x 

fact = 1 fby (fact * (pos +1)) 

fibo = 0 fby (fibo + (1 fby fibo)) 

The value of pos is 0 at the beginning of the history and at every other instant 
it is the immediately preceding value incremented by one, i.e., pos generates the 
enumeration of all natural numbers. The function sum finds the accumulated 
sum of all values of the input up to the current instant. The function diff finds 
the difference between the current value and the immediately preceding value of 
the input. The function ini generates the constant sequence of the initial value 
of the input. Finally, fact and fibo generate the graphs of the factorial and 
Fibonacci functions respectively. Their behaviour is illustrated below. 
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pos 0 I 2 3 4 5 6 77. 

sum pos 0 1 3 6 10 15 21 777 

dif f pos' 0 1 1 1 1 1 1 

ini pos 0 0 0 0 0 0 0 

fact 1 1 2 6 24 120 720 777 

fibo 0 1 1 2 3 5 8 

An expression written with pointwise constructs and f by is always causal in 
the sense that its present value can only depend on the past and present values of 
its variables. In languages a la Lucid, one can also write more general expressions 
with physically unrealistic dependencies on future values of the variables. This is 
supported by a construct called next. The value of next e at the current instant 
is the value of e at the immediately following instant, so the signal next e is the 
unit anticipation of the signal e. 

— X | Xp Xl X2 X3 X4 Xs 

next x| Xl _ X2 _ X3 _£4_ X5 _£6_ 

Combining next with recursion, it is possible to define functions whose present 
output value can depend on the value of the input in unboundedly distant future. 
For instance, the sieve of Eratosthenes can be defined as follows. 

x wvr y = if ini y then x fby (next x wvr next y) 
else (next x wvr next y) 

sieve x = x fby sieve (x wvr x mod (ini x) /= 0) 
eratosthenes = sieve (pos + 2) 

The filtering function wvr (pronounced “whenever”) returns the substream 
of the first input stream consisting of its elements from the positions where the 
second input stream is true-valued. (This is all well as long as there always is a 
future position where the second input stream has the value true, but poses a 
problem, if from some point on it is constantly false.) The function sieve outputs 
the initial element of the input stream and then recursively calls itself on the 
substream of the input stream that only contains the elements not divisible by 
the initial element. 
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Because anticipation is physically unimplementable and the use of it may 
result in unbounded lookaheads, most dataflow languages do not support it. 
Instead, some of them provide means to define partial streams, i.e., streams 
where some elements can be undefined (denoted below by —). The idea is that 
different signals may be on different clocks. Viewed as signals on the fastest 
(base) clock, they are not defined at every instant. They are only defined at 
those instants of the base clock that are also instants of their own clocks. 
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One possibility to specify partial streams is to introduce new constructs nosig 
and merge (also known as “default”). The constant nosig denotes a constantly 
undefined stream. The operator merge combines two partial streams into a par¬ 
tial stream that is defined at the positions where at least one of two given partial 
streams is defined (where both are defined, there the first one takes precedence). 

nosig — — — — — — 

x xo — — X3 — — 

y _ - - yi m - ys 

merge x y| x 0 - y 2 x 3 - y 5 

With the feature of partiality, it is possible to define the sieve of Eratosthenes 
without anticipation. 

sieve x = if (tt fby ff) then x 

else sieve (if (x mod ini x /= 0) then x else nosig) 
eratosthenes = sieve (pos + 2) 

The initial element of the result of sieve is the initial element of the input 
stream whereas all other elements are given by a recursive call on the modified 
version of the input stream where all positions containing elements divisible by 
the initial element have been dropped. 
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3 Monads and Monadic Interpreters 

3.1 Monads and Effect-Producing Functions 

Now we proceed to monads and monadic interpreters. We begin with a brief 
recapitulation of the monad-based approach to representing effectful functions 
12614014116] . 

A monad (in extension form) on a category C is given by a mapping T : \C\ —* 
\C\ together with a |C (-indexed family r] of maps t/a '■ A —► TA of C (unit), and 
an operation —* taking every map k : A —► TB in C to a map k* : TA —» TB of 
C ( extension operation ) such that 

1. for any / : A —> TB, k* o t]a = k, 

2. rjA* = id-r.4, 

3. for any k : A—> TB, l: B —> TC, (P o k)* = £* o k*. 

Monads are a construction with many remarkable properties, but the cen¬ 
tral one for programming and semantics is that any monad ( T,r) ,—*) defines 
a category Ct where \Ct\ = \C\ and Ct(A,B) = C(A,TB), (id'j^A = Va, 
i o T k = £* o k ( Kleisli category) and an identity on objects functor J : C —> Ct 
where Jf = t)b ° / for / : A —» B. 

In the monadic approach to effectful functions, the underlying object mapping 
T of a monad is seen as an abstraction of the kind of effect considered and assigns 
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to any type A a corresponding type TA of “computations of values” or “values 
with an effect”. An effectful function from A to B is identified with a map A —> B 
in the Kleisli category, i.e., a map A —► TB in the base category. The unit of 
the monad makes it possible to view any pure function as an effectful one while 
the extension operation provides composition of effect-producing functions. Of 
course monads capture the structure that is common to all notions of effectful 
function. Operations specific to a particular type of effect are not part of the 
corresponding monad structure. 

There are many standard examples of monads in semantics. Here is a brief 
list of examples. In each case, the object mapping T is a monad. 

— TA = A, the identity monad, 

— TA = Maybe A = A + 1, error (undefinedness), TA = A + E, exceptions, 

— TA = List A = /iX. l + A x X, non-determinism, 

— TA = E =$■ A, readable environment, 

— TA=S=>AxS, state, 

— TA = (A =>• R) =>■ R, continuations, 

— TA = /.iX.A + (U => X), interactive input, 

— TA = jiX.A + V x X = Ax ListIA, interactive output, 

— TA = fiX.A + FX, the free monad over F, 

— TA = vX.A + FX, the free completely iterative monad over F pQ. 

(By /x and v we denote the least and greatest fixpoints of functors.) 

In Haskell, monads are implemented as a type constructor class with two 
member functions (in the Prelude): 

class Monad t where 

(»=) : : t a -> (a -> t b) -> t b 

mmap :: Monad t => (a -> b) -> t a -> t b 
mmap f c = c »= (return . f) 

return is the Haskell name for the unit and (»=) (pronounced ’bind’) is the 
extension operation of the monad. Haskell also supports a special syntax for 
defining Kleisli arrows, but in this paper we will avoid it. 

In Haskell, every monad is strong in the sense that carries an additional op¬ 
eration, known as strength, with additional coherence properties. This happens 
because the extension operations of Haskell monads are necessarily internal. 

mstrength :: Monad t => t a -> b -> t (a, b) 
mstrength c b = c »= \ a -> return (a, b) 

The identity monad is Haskell-implemented as follows, 
newtype Id a = Id a 

instance Monad Id where 
return a = Id a 
Id a »= k = k a 
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The definitions of the maybe and list monads are the following. 

data Maybe a = Just a I Nothing 

instance Monad Maybe where 
return a = Just a 

Just a »= k = k a 
Nothing »= k = Nothing 

data [a] = [] la: [a] 

instance Monad [] where 
return a = [a] 

□ »= k = [] 

(a : as) »= k = k a ++ (as »= k) 

The exponent and state monads are defined in the following fashion. 

newtype Exp e a = Exp (e -> a) 

instance Monad (Exp e) where 

return a = Exp (\ _ -> a) 

Exp f »= k = Exp (\ e -> case k (f e) of 

Exp f’ -> f’ e) 

newtype State s a = State (s -> (a, s)) 

instance Monad (State s) where 

return a = State (\ s -> (a, s)) 

State f »= k = State (\ s -> case f s of 

(a, s’) -> case k a of 
State f’ -> f’ s’) 

In the case of these monads, the operations specific to the type of effect 
they characterize are raising and handling an error, nullary and binary non- 
deterministic choice, consulting and local modification of the environment, con¬ 
sulting and updating the state. 

raise :: Maybe a 
raise = Nothing 

handle :: Maybe a -> Maybe a -> Maybe a 
Just a ‘handle' _ = Just a 
Nothing 'handle' c = c 

deadlock :: [a] 
deadlock = [] 

choice : : [a] -> [a] -> [a] 
choice asO asl = asO ++ asl 
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askE : : Exp e e 
askE = Exp id 

localE :: (e -> e) -> Exp e a -> Exp e b 
localE g (Exp f) = Exp (f . g) 

get :: State s s 

get = State (\ s -> (s, s)) 

put : : s -> State s () 

put s = State (\ _ -> ((), s)) 

3.2 Monadic Semantics 

Monads are a perfect tool for formulating denotational semantics of languages for 
programming effectful functions. If this is done in a functional (meta-)language, 
one obtains a reference interpreter for free. Let us recall how this project was carried 
out by Moggi and Wadler. Of course we choose Haskell as our metalanguage. 

We proceed from a simple strongly typed purely functional (object) language 
with two base types, integers and booleans, which we want to be able to extend 
with various types of effects. As particular examples of types of effects, we will 
consider errors and non-determinism. 

The first thing to do is to define the syntax of the object language. Since 

Haskell gives us no support for extensible variants, it is simplest for us to include 

the constructs for the two example effects from the beginning. For errors, these 
are error raising and handling. For non-determinism, we consider nullary and 
binary branching. 

type Var = String 

data Tm = V Var I L Veit Tm I Tm Tm 
I N Integer I Tm :+ Tm I ... 

I Tm :== Tm | ... I TT I FF I Not Tm I ... I If Tm Tm Tm 

— specific for Maybe 

I Error I Tm ‘Handle' Tm 

— specific for [] 

I Deadlock I Tm ‘Choice' Tm 

In the definition above, the constructors V, L, (:@) correspond to variables, 
lambda-abstraction and application. The other names should be self-explanatory. 

Next we have to define the semantic domains. Since Haskell is not dependently 
typed, we have to be a bit coarse here, collecting the semantic values of all object 
language types (for one particular type of effect) into a single type. But in reality, 
the semantic values of the different object language types are integers, booleans 
and functions, respectively, with no confusion. Importantly, a function takes a 
value to a value with an effect (where the effect can only be trivial in the pure 
case). An environment is a list of variable-value pairs, where the first occurrence 
of a variable in a pair in the list determines its value. 
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data Val t = I Integer I B Bool I F (Val t -> t (Val t)) 
type Env t = [(Var, Val t)] 

We will manipulate environment-like entities via the following three functions. 
(The safe lookup, that maybe returns a value, will be unnecessary, since we can 
type-check an object-language term before evaluating it. If this succeeds, we can 
be sure we will only be looking up variables in environments where they really 
occur.) 

empty :: [(a, b)] 
empty = [] 

update : : a -> b -> [(a, b)] -> [(a, b)] 
update a b abs = (a, b) : abs 

unsafeLookup :: Eq a => a -> [(a, b)] -> b 

unsafeLookup aO ((a,b):abs) = if aO == a then b else unsafeLookup aO abs 

The syntax and the semantic domains of the possible object languages de¬ 
scribed, we can proceed to evaluation. 

The pure core of an object language is interpreted uniformly in the type of 
effect that this language supports. Only the unit and bind operations of the 
corresponding monad have to be known to describe the meanings of the core 
constructs. 

class Monad t => MonadEv t where 
ev :: Tm -> Env t -> t (Val t) 


evClosed :: MonadEv t => Tm -> t (Val t) 
evClosed e = ev e empty 


_ev :: MonadEv 
_ev (V x) 

_ev (L x e) 

_ev (e :fl e>) 


_ev (N n) 

_ev (eO :+ el) 


_ev TT 
_ev FF 
_ev (Not e) 


=> Tm -> Env t -> t (Val t) 
env = return (unsafeLookup x env) 
env = return (F (\ a -> ev e (update 
env = ev e env »= \ (F k) -> 

ev e> env »= \ a -> 

k a 

env = return (In) 
env = ev eO env »= \ (I nO) -> 

ev el env »= \ (I nl) -> 

return (I (nO + nl)) 

env = return (B True ) 
env = return (B False) 
env = ev e env »= \ (B b) -> 
return (B (not b)) 


_ev (If e eO el) env = ev e env »= \ (B b) -> 

if b then ev eO env else ev el 


env))) 
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To interpret the “native” constructs in each of the extensions, we have to use 
the “native” operations of the corresponding monad. 

instance MonadEv Id where 


instance MonadEv Maybe where 
ev Raise env = raise 

ev (eO ‘Handle* el) env = ev eO 


‘handle‘ 


instance MonadEv [] where 

ev Deadlock env = deadlock 

ev (eO ‘Choice' el) env = ev eO env 


We have achieved nearly perfect reference interpreters for the three languages. 
But there is one thing we have forgotten. To accomplish anything really inter¬ 
esting with integers, we need some form of recursion, say, the luxury of general 
recursion. So we would actually like to extend the definition of the syntax by 
the clause 

data Tm = ... I Rec Tm 

It would first look natural to extend the definition of the semantic intepretation 
by the clause 

_ev (Rec e) env = ev e env »= \ (F k) -> 

_ev (Rec e) env »= \ a -> 
k a 

But unfortunately, this interprets Rec too eagerly, so no recursion will ever stop. 
For every recursive call in a recursion, the interpreter would want to know if it 
returns, even if the result is not needed at all. 

So we have a problem. The solution is to use the MonadFix class (from Con¬ 
trol.Monad.Fix), an invention of Erkok and Launchbury |16| , which specifically 
supports the monadic form of general recursion 0: 

class Monad t => MonadFix t where 
mfix :: (a -> t a) -> t a 

— the ideal uniform mfix which doesn’t work 

— mfix k = mfix k »= k 

The identity, maybe and list monads are instances (in an ad hoc way). 

1 Notice that ‘Fix’ in ‘MonadFix’ refers as much to fixing an unpleasant issue as it 
refers to a fixpoint combinator. 
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fix :: (a -> a) -> a 
fix f = f (fix f) 

instance MonadFix Id where 
mfix k = fix (k . unld) 

where unld (Id a) = a 

instance MonadFix Maybe where 
mfix k = fix (k . unjust) 

where unjust (Just a) = a 

instance MonadFix [] where 

mfix k = case fix (k . head) of 
[] -> □ 

(a : _) -> a : mfix (tail . k) 

Now, after subclassing MonadEv from MonadFix instead of Monad 
class MonadFix t => MonadEv t where ... 
we can define the meaning of Rec by the clause 

_ev (Rec e) env = ev e env »= \ (F k) -> 
mfix k 

After this dirty fix (where however all dirt is contained) everything is clean 
and working. We can interpret our pure core language and the two extensions. 
The examples from the Introduction are handled by the interpreter exactly as 
expected. We can define: 

fact = Rec (L "fact" (L "x" ( 

If (V "x" :<= N 1) 

(N 1) 

((V "fact" :<§ (V "x" N 1)) :* V "x")))) 

factM = Rec (L "fact" (L "x" ( 

(If (V "x" :== N 5) 

(If (V "x" :<= N 1) 

(N 1) 

((V "fact" :® (V "x" N 1)) :* V "x"))) 

‘Handle' 

(If (V "x" :== N 7) 

(N 5040) 

Raise)))) 

factL = Rec (L "fact" (L "x" ( 

If (V "x" :<= N 1) 

(N 1) 

((V "fact" :0 (V "x" N 1)) :* 

(N 1 ‘Choice' V "x"))))) 
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Testing these, we get exactly the results we would expect. 


> evClosed (fact 


0 6 ) 


Id (Val Id) 


Id 720 

> evClosed (factM 
Just 24 

> evClosed (factM 
Nothing 

> evClosed (factM 
Just 40320 

> evClosed (factL 
[1,5,4,20,3,15,12,60, 


N 4) 
N 6) 


Maybe (Val Maybe) 

Maybe (Val Maybe) 

Maybe (Val Maybe) 

[Val []] 
2,10,8,40,6,30,24,120] 


4 Arrows 

Despite their generality, monads do not cater for every possible notion of impure 
function. In particular, monads do not cater for stream functions, which are the 
central concept in dataflow programming. 

In functional programming, Hughes m has been promoting what he has 
called arrow types to overcome this deficiency. In semantics, the same concept 
was invented for the same reason by Power and Robinson |32] under the name 
of a Freyd category. 

Informally, a Freyd category is a symmetric premonoidal category together 
and an inclusion from a base category. A symmetric premonoidal category is 
the same as a symmetric monoidal category except that the tensor need not be 
bifunctorial, only functorial in each of its two arguments separately. 

The exact definition is a bit more complicated: A binoidal category is a cat¬ 
egory K. binary operation ® on objects of K. that is functorial in each of its 
two arguments. A map / : A —* B of such a category is called central if the 
two composites A 0 C —* B ® D agree for every map g : C —> D and so do 
the two composites C 0 A —> D ® B. A natural transformation is called central 
if its components are central. A symmetric premonoidal category is a binoidal 
category (/C, (g>) together with an object I and central natural transformations 
p, a, <7 with components A —> A®I, (A<g>B)®C —> A ® (B®C), A®B —> B<g> A, 
subject to a number of coherence conditions. A Freyd category over a Cartesian 
category C is a symmetric premonoidal category /C together with an identity on 
objects functor J : C —> /C that preserves the symmetric premonoidal structure 
of C on the nose and also preserves centrality. 

The pragmatics for impure computation is to have an inclusion from the base 
category of pure functions to a richer category of which is the home for impure 
functions (arrows), so that some aspects of the Cartesian structure of the base 
category are preserved. Importantly the Cartesian product x of C is bifunctorial, 
so (B x g) o (/ x C) = {f x D) o (A x g) : A x C -> B x D for any / : A -> B 
and g : C —> D, but for the corresponding tensor operation ® of 1C this is only 
mandatory if either / or g is pure (the idea being that different sequencings of 
impure functions must be able to give different results). 
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The basic example of a Freyd category is the Kleisli category of a strong 
monad. Another standard one is that of stateful functions. For a base category C, 
the maps of the Freyd category are the maps AxS —> B x S of C where S is some 
fixed object of C. This is not very exciting, since if C also has exponents, the maps 
Ax S —> B x S are in a natural bijection with the maps A —> S => B x S, which 
means that the Freyd category is essentially the same as the Kleisli category of 
the state monad. But probably the best known and most useful example is that 
of stream functions. In this case the maps A —> B of the Freyd category are the 
maps StrA — > StrB of C of C where StrA = vX.A x X is the type of streams over 
the type A. Notice that differently from stateful functions from A to B, stream 
functions from A to B just cannot be viewed as Kleisli arrows. 

In Haskell, arrow type constructors are implemented by the following type 
constructor class (appearing in Control.Arrow). 

class Arrow r where 

pure :: (a -> b) -> r a b 
(»>) :: rab->rbc->rac 
first :: r a b -> r (a, c) (b, c) 

returnA :: Arrow r => r a a 
returnA = pure id 

second :: Arrow r => r c d -> r (a, c) (a, d) 
second f = pure swap »> first f »> pure swap 

pure says that every function is an arrow (so in particular identity arrows arise 
from identity functions). (»>) provides composition of arrows and first pro¬ 
vides functoriality in the first argument of the tensor of the arrow category. 

In Haskell, Kleisli arrows of monads are shown to be an instance of arrows as 
follows (recall that all Haskell monads are strong). 

newtype Kleisli t a b = Kleisli (a -> t b) 

instance Monad t => Arrow (Kleisli t) where 
pure f = Kleisli (return . f) 

Kleisli k »> Kleisli 1 = Kleisli ((»= 1) . k) 

first (Kleisli k) = Kleisli (\ (a, c) -> mstrength (k a) c) 

Stateful functions are a particularly simple instance, 
newtype StateA s a b = StateA ((a, s) -> (b, s)) 

instance Arrow (State A s) where 

pure f = StateA (\ (a, s) -> (f a, s)) 

StateA f »> StateA g = StateA (g . f) 

first (StateA f) = StateA (\ ((a, c), s) -> case f (a, s) of 

(b, s’) -> ((b, c), s’)) 


Stream functions are declared to be arrows in the following fashion, relying 
on streams being mappable and zippable. (For reasons of readability that will 
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become apparent in the next section, we introduce our own list and stream 
types with our own names for their nil and cons constructors. Also, although 
Haskell does not distinguish between inductive and coinductive types because 
of its algebraically compact semantics, we want to make the distinction, as our 
work also applies to other, finer semantic models.) 

data Stream a = a :< Stream a — coinductive 

mapS :: (a -> b) -> Stream a -> Stream b 
mapS f (a :< as) = f a :< mapS f as 

zipS :: Stream a -> Stream b -> Stream (a, b) 
zipS (a :< as) (b :< bs) = (a, b) :< zipS as bs 

unzipS :: Stream (a, b) -> (Stream a, Stream b) 
unzipS abs = (mapS fst abs, mapS snd abs) 

newtype SF a b = SF (Stream a -> Stream b) 

instance Arrow SF where 
pure f = SF (mapS f) 

SF k »> SF 1 = SF (1 . k) 

first (SF k) = SF (uncurry zipS . (\ (as, ds) -> (k as, ds)) . unzipS) 

Similarly to monads, every useful arrow type constructor has some operation 
specific to it. The main such operation for stream functions are the initialized 
unit delay operation ‘followed by’ of intensional and synchronous dataflow lan¬ 
guages and the unit anticipation operation ‘next’ that only exists in intensional 
languages. These are really the cons and tail operations of streams. 

fbySF : : a -> SF a a 

fbySF aO = SF (\ as -> aO :< as) 

nextSF :: SF a a 

nextSF = SF (\ (a :< as) -> as) 


5 Comonads 

5.1 Comonads and Context-Dependent Functions 

While Freyd categories or arrow types are certainly general and cover signifi¬ 
cantly more notions of impure functions than monads, some non-monadic impu¬ 
rities should be explainable in more basic terms, namely via comonads, which 
are the dual of monads. This has been suggested |8I23I25| . but there have been 
few useful examples. One of the goals of this paper is to show that general and 
causal stream functions are excellent new such examples. 

A comonad on a category C is given by a mapping D : \C\ —► \C\ together with a 
\C (-indexed family e of maps ea '■ DA —► A {counit), and an operation — t taking 
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every map k : DA —> B in C to a map k' : DA —> DB ( coextension operation) 
such that 

1. for any k : DA —> B, e B ° ftt = k, 

2. e J 4 1 ' = id da, 

3. for any k : DA —> B, £ : DB —> C, (£o Jfct)t = g\ 0 jfet. 

Analogously to Kleish categories, any comonad (D,e —t) defines a category 
C D where \C D \ = \C\ and C D (A,B ) = C(DA,B ), (kb) a = e A , £o D k = £otf 
( coKleisli category) and an identity on objects functor J : C —> Cd where Jf = 
f o e A for / : A -► B. 

Comonads should be fit to capture notions of “value in a context”; DA would 
be the type of contextually situated values of A. A context-dependent function 
from A to B would then be a map A —» B in the coKleisli category, i.e., a map 
DA —> B in the base category. The function e A ■ DA —*■ A discards the context 
of its input whereas the coextension k' : DA —» DB of a function k : DA —» B 
essentially duplicates it (to feed it to k and still have a copy left). 

Some examples of comonads are the following: each object mapping D below 
is a comonad: 

— DA = A, the identity comonad, 

— DA = A x E, the product comonad, 

— DA = StrA = vX.A x X, the streams comonad, 

— DA = vX.A x FX, the cofree comonad over F, 

— DA = gX.A x FX, the cofree recursive comonad over F [55] , 

Accidentally, the pragmatics of the product comonad is the same as that of 
the exponent monad, viz. representation of functions reading an environment. 
The reason is simple: the Kleisli arrows of the exponent monad are the maps 
A —* (E => B) of the base category, which are of course in a natural bijection 
with the with the maps Ax E —> B that are the coKleisli arrows of the product 
comonad. But in general, monads and comonads capture different notions of im¬ 
pure function. We defer the discussion of the pragmatics of the streams comonad 
until the next subsection (it is not the comonad to represent general or causal 
stream functions!). 

For Haskell, there is no standard comonad librarj@. But of course comonads 
are easily defined as a type constructor class analogously to monads. 

class Comonad d where 
counit :: d a -> a 
cobind :: (d a -> b) -> d a -> d b 

cmap :: Comonad d => (a -> b) -> d a -> d b 
cmap f = cobind (f . counit) 

The identity and product comonads are defined as instances in the following 
fashion. 

2 There is, however, a contributed library by Dave Menendez, 
eyrie.org/~zednenem/2004/hsce/ 


http://www. 
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instance Comonad Id where 
counit (Id a) = a 
cobind k d = Id (k d) 

data Prod e a = a :& e 

instance Comonad (Prod e) where 
counit (a :& _) = a 
cobind k d@(_ :& e) = k d :k e 

askP :: Prod e a -> e 
askP (_ :& e) = e 

localP :: (e -> e) -> Prod e a -> Prod e a 
localP g (a :& e) = (a :& g e) 

The stream comonad is implemented as follows. 

instance Comonad Stream where 
counit (a :< _) = a 

cobind k d@(_ :< as) = k d :< cobind k as 

nextS :: Stream a -> Stream a 
nextS (a :< as) = as 

Just as the Kleisli categories of strong monads are Freyd categories, so are 
the coKleisli categories of comonads, 
newtype CoKleisli d a b = CoKleisli (d a -> b) 
pair f g x = (f x, g x) 

instance Comonad d => Arrow (CoKleisli d) where 
pure f = CoKleisli (f . counit) 

CoKleisli k »> CoKleisli 1 = CoKleisli (1 . cobind k) 

first (CoKleisli k) = CoKleisli (pair (k . cmap fst) (snd . counit)) 

5.2 Comonads for General and Causal Stream Functions 

The general pragmatics of comonads introduced, we are now ready to discuss 
the representation of general and causal stream functions via comonads. 

The first observation to make is that streams (discrete time signals) are nat¬ 
urally isomorphic to functions from natural numbers: StrA = vX. A x X = 
(, fiX . 1 + X) =>■ A = Nat => A. In Haskell, this isomorphism is implemented as 
follows: 

str2fun :: Stream a -> Int -> a 

str2fun (a :< as) 0 = a str2fun (a :< as) (i + 1) = str2fun as i 

fun2str :: (Int -> a) -> Stream a 
fun2str f = fun2str’ f 0 

where fun2str’ f i = f i :< fun2str’ f (i + 1) 
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General stream functions StrA —► StrB are thus in natural bijection with 
maps Nat => A —> Nat => B, which, in turn, are in natural bijection with maps 
(Nat => A) x Nat —> B, i.e., FunArg Nat A —> B where FunArg S A = (S => A) x S. 
Hence, for general stream functions, a value from A in context is a stream (sig¬ 
nal) over A together with a natural number identifying a distinguished stream 
position (the present time). Not surprisingly, the object mapping FunArg S' is a 
comonad (in fact, it is the “state-in-context” comonad considered by Kieburtz 
[23] ) and, what is of crucial importance, the coKleisli identities and composi¬ 
tion as well as the coKleisli lifting of FunArg Nat agree with the identities and 
composition of stream functions (which are really just function identities and 
composition) and with the lifting of functions to stream functions. In Haskell, 
the parameterized comonad FunArg and the interpretation of the coKleisli arrows 
of FunArg Nat as stream functions are implemented as follows. 

data FunArg s a = (s -> a) :# s 

instance Comonad (FunArg s) where 
counit (f :# s) = f s 

cobind k (f :# s) = (\ s’ -> k (f :# s’)) :# s 

runFA :: (FunArg Int a -> b) -> Stream a -> Stream b 
runFA k as = runFA’ k (str2fun as :# 0) 

where runFA’ k d@(f :# i) = k d :< runFA’ k (f :# (i + 1)) 

The comonad FunArg Nat can also be presented equivalently without using 
natural numbers to deal with positions. The idea for this alternative presentation 
is simple: given a stream and a distinguished stream position, the position splits 
the stream up into a list, a value of the base type and a stream (corresponding 
to the past, present and future of the signal). Put mathematically, there is a 
natural isomorphism (Nat => A) x Nat = StrA x Nat AS (List A x A) x StrA 
where List A = /jlX. 1 + (A x X) is the type of lists over a given type A. This 
gives us an equivalent comonad LVS for representing of stream functions with 
the following structure (we use snoc-lists instead of cons-lists to reflect the fact 
that the analysis order of the past of a signal will be the reverse direction of 
time): 

data List a = Nil I List a :> a — inductive 

data LV a = List a := a 

data LVS a = LV a :I Stream a 

instance Comonad LVS where 
counit (az := a :I as) = a 
cobind k d = cobindL d := k d :I cobindS d 

where cobindL (Nil := a :I as) = Nil 

cobindL (az’ :> a’ := a :I as) = cobindL d’ :> k d’ 

where d’ = az’ := a’ :| (a :< as) 
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cobindS (az := a :I (a’ :< as’)) = k d’ :< cobindS d’ 

where d’ = az :> a := a’ : I as’ 

(Notice the visual purpose of our constructor naming. In values of types LVS A, 
both the cons constructors (:>) of the list (the past) and the cons constructors 
(:<) of the stream (the future) point to the present which is enclosed between 
the constructors (:=) and (: |).) 

The interpretation of the coKleisli arrows of the comonad LVS as stream 
functions is implemented as follows. 

runLVS :: (LVS a -> b) -> Stream a -> Stream b 

runLVS k (a’ :< as’) = runLVS’ k (Nil := a’ :| as’) 

where runLVS’ k d@(az := a :I (a’ :< as’)) 

= k d :< runLVS’ k (az :> a := a’ :I as’) 

Delay and anticipation are easily formulated in terms of both FunArg Nat and 
LVS. 

fbyFA :: a -> (FunArg Int a -> a) 
fbyFA aO (f :# 0) = aO 

fbyFA _ (f :# (i + 1)) = f i 

fbyLVS :: a -> (LVS a -> a) 
fbyLVS aO (Nil :I _) = aO 

fbyLVS _ ((_ :> a’) :I _) = a’ 

nextFA :: FunArg Int a -> a 
nextFA (f :# i) = f (i + 1) 

nextLVS : : LVS a -> a 

nextLVS (_ := _ : I (a :< _)) = a 

Let us call a stream function causal, if the present of the output signal only 
depends on the past and present of the input signal and not on its futurqd- Is there 
a way to ban non-causal functions? Yes, the comonad LVS is easy to modify so 
that exactly those stream functions can be represented that are causal. All that 
needs to be done is to remove from the comonad LVS the factor of the future. We 
are left with the object mapping LV where LV A = List A x A = (jiX. 1 + A x X) x 
A = fj,X. Ax (1 + X), i.e., a non-empty list type constructor. This is a comonad 
as well and again the counit and the coextension operation are just correct in the 
sense that they deliver the desirable coKleisli identities, composition and lifting. 
In fact, the comonad LV is the cofree recursive comonad of the functor Maybe 
(we refrain from giving the definition of a recursive comonad here, this can be 

3 The standard terminology is ‘synchronous stream functions’, but want to avoid it, 
because ‘synchrony’ also refers to all signals being on the same clock and to the 
hypothesis on which the applications of synchronous dataflow languages are based: 
that in an embedded system the controller can react to an event in the plant in so 
little time that it can be considered instantaneous. 
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found in [US]). It may be useful to notice that the type constructor LV carries a 
monad structure too, but the Kleisli arrows of that monad have nothing to do 
with causal stream functions! 

In Haskell, the non-empty list comonad LV is defined as follows. 

instance Comonad LV where 
counit (_ := a) = a 

cobind k d@(az := _) = cobindL k az := k d 
where cobindL k Nil = Nil 

cobindL k (az :> a) = cobindL k az :> k (az := a) 

runLV :: (LV a -> b) -> Stream a -> Stream b 
runLV k (a’ :< as’) = runLV’ k (Nil := a’ :I as’) 

where runLV’ k (d@(az := a) :I (a’ :< as’)) 

= k d :< runLV’ k (az :> a := a’ :I as’) 

With the LV comonad, anticipation is no longer possible, but delay is unprob¬ 
lematic. 

fbyLV :: a -> (LV a -> a) 
fbyLV aO (Nil := _) = aO 

fbyLV _ ((_ :> a’) := _) = a’ 

Analogously to causal stream functions, one might also consider anticausal 
stream functions, i.e., functions for which the present value of the output sig¬ 
nal only depends on the present and future values of the input signal. As 
A x Str A = Str A, it is not surprising now anymore that the comonad for an¬ 
ticausal stream functions is the comonad Str, which we introduced earlier and 
which is very canonical by being the cofree comonad generated by the identity 
functor. However, in real life, causality is much more relevant than anticausality! 


5.3 Comonadic Semantics 

Is the comonadic approach to context-dependent computation of any use? We 
will now demonstrate that it is indeed by developing a generic comonadic in¬ 
terpreter instantiable to various specific comonads, in particular to those that 
characterize general and causal stream functions. In the development, we mimic 
the monadic interpreter. 

As the first thing we again fix the syntax of our object language. We will 
support a purely functional core and additions corresponding to various notions 
of context. 

type Var = String 

data Tm = V Var I L Var Tm I Tm Tm I Rec Tm 
I N Integer I Tm :+ Tm I ... 

I Tm :== Tm | ... I TT I FF I Not Tm I ... I If Tm Tm Tm 
— specific for both general and causal stream functions 
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I Tm ‘Fby‘ Tm 

— specific for general stream functions only 
I Next Tm 

The type-unaware semantic domain contains integers, booleans and functions 
as before, but now our functions are context-dependent (coKleisli functions). 
Environments are lists of variable-value pairs as usual. 

data Val d = I Integer I B Bool I F (d (Val d) -> Val d) 

type Env d = [(Var, Val d)] 

And we are at evaluation. Of course terms must denote coKleisli arrows, so 
the typing of evaluation is uncontroversial. 

class Comonad d => ComonadEv d where 
ev :: Tm -> d (Env d) -> Val d 

But an interesting issue arises with evaluation of closed terms. In the case of 
a pure or a monadically interpreted language, closed terms are supposed to 
be evaluated in the empty environment. Now they must be evaluated in the 
empty environment placed in a context! What does this mean? This is easy to 
understand on the example of stream functions. By the types, evaluation of an 
expression returns a single value, not a stream. So the stream position of interest 
must be specified in the contextually situated environment that we provide. Very 
suitably, this is exactly the information that the empty environment in a context 
conveys. So we can define: 

evClosedl :: Tm -> Val Id 
evClosedl e = ev e (Id empty) 

emptyL :: Int -> List [(a, b)] 

emptyL 0 = Nil 

emptyL (i + 1) = emptyL i :> empty 

emptyS :: Stream [(a, b)] 
emptyS = empty :< emptyS 

evClosedLVS :: Tm -> Int -> Val LVS 

evClosedLVS e i = ev e (emptyL i := empty :I emptyS) 

evClosedLV :: Tm -> Int -> Val LV 
evClosedLV e i = ev e (emptyL i := empty) 

Back to evaluation. For most of the core constructs, the types tell us what 
the defining clauses of their meanings must be—there is only one thing we can 
write and that is the right thing. In particular, everything is meaningfully pre¬ 
determined about variables, application and recursion (and, for recursion, the 
obvious solution works). E.g., for a variable, we must extract the environment 
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from its context (e.g., history), and then do a lookup. For an application, we 
must evaluate the function wrt. the given contextually situated environment 
and then apply it. But since, according to the types, a function wants not just 
an isolated argument value, but a contextually situated one, the function has to 
be applied to the coextension of the denotation of the argument wrt. the given 
contextually situated environment. 


_ev : : ComonadEv d => 


_ev (V x) denv 

_ev (e e’) denv 

_ev (Rec e) denv 

_ev (N n) denv 

_ev (eO :+ el) denv 


Tm -> d (Env d) -> Val d 
= unsafeLookup x (counit denv) 

= case ev e denv of 

F f -> f (cobind (ev e’) denv) 

F f -> f (cobind (_ev (Rec e)) 
= I n 

= case ev eO denv of 




I nO -> case ev el denv of 
I nl -> I (nO + nl) 


_ev TT 
_ev FF 
_ev (Not e) 


denv = B True 
denv = B False 
denv = case ev e denv of 
B b -> B (not b) 


_ev (If e eO el) denv = case ev e denv of 

B b -> if b then ev eO denv else ev el denv 


There is, however, a problem with lambda-abstraction. For any potential con¬ 
textually situated value of the lambda-variable, the evaluation function should 
recursively evaluate the body of the lambda-abstraction expression in the ap¬ 
propriately extended contextually situated environment. Schematically, 

_ev (L x e) denv = F (\ d -> ev e (extend x d denv)) 

where 

extend :: Comonad d => Var -> d (Val d) -> d (Env d) -> d (Env d) 

Note that we need to combine a contextually situated environment with a con¬ 
textually situated value. One way to do this would be to use the strength of the 
comonad (we are in Haskell, so every comonad is strong), but in the case of the 
stream function comonads this would necessarily have the bad effect that either 
the history of the environment or that of the value would be lost. We would like 
to see that no information is lost, to have the histories zipped. 

To solve the problem, we consider comonads equipped with an additional 
zipping operation. We define a comonad with zipping to be a comonad D coming 
with a natural transformation m with components toa,b : DA x DB —» D(A x 
B) that satisfies coherence conditions such as eaxb ° 'oia,b = £a x £b (more 
mathematically, this is a symmetric semi-monoidal comonad). 

In Haskell, we define a corresponding type constructor class. 
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class Comonad d => ComonadZip d where 
czip :: d a -> d b -> d (a, b) 

The identity comonad, as well as LVS and LV are instances (and so are many 
other comonads). 

instance ComonadZip Id where 
czip (Id a) (Id b) = Id (a, b) 

zipL :: List a -> List b -> List (a, b) 

zipL Nil _ = Nil 

zipL _ Nil = Nil 

zipL (az :> a) (bz :> b) = zipL az bz :> (a, b) 

zipS :: Stream a -> Stream b -> Stream (a, b) 

zipS (a :< as) (b :< bs) = (a, b) :< zipS as bs 

instance ComonadZip LVS where 

czip (az := a :| as) (bz := b :| bs) 

= zipL az bz := (a, b) :I zipS as bs 


instance ComonadZip LV where 

czip (az := a) (bz := b) = zipL az bz := (a, b) 

With the zip operation available, defining the meaning of lambda-abstractions 
is easy, but we must also update the typing of the evaluation function, so that 
zippability becomes requirecQ. 

class ComonadZip d => ComonadEv d where ... 

_ev (L x e) denv = F (\ d -> ev e (cmap repair (czip d denv))) 
where repair (a, env) = update x a env 

It remains to define the meaning of the specific constructs of our example 
languages. The pure language has none. The dataflow languages have Fby and 
Next that are interpreted using the specific operations of the corresponding 
comonads. Since each of Fby and Next depends on the context of the value of its 
main argument, we need to apply the coextension operation to the denotation 
of that argument to have this context available. 

instance ComonadEv Id where 
ev e denv = _ev e denv 

instance ComonadEv LVS where 

ev (eO ‘Fby‘ el) denv = ev eO denv ‘fbyLVS' cobind (ev el) denv 
ev (Next e) denv = nextLVS (cobind (ev e) denv) 

ev e denv = _ev e denv 


The name ‘repair’ in the code below alludes both to getting a small discrepancy ii 
the types right and to rearranging some pairings. 
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instance ComonadEv LV where 

ev (eO ‘Fby' el) denv = ev eO denv 'fbyLV' cobind (ev el) denv 
ev e denv = _ev e denv 

In dataflow languages, the ‘followed by’ construct is usually defined to mean 
the delay of the second argument initialized by the initial value of the first 
argument, which may at first seem like an ad hoc decision (or so it seemed 
to us at least). Why give the initial position any priority? In our interpreter, 
we took the simplest possible solution of using the value of the first argument 
of Fby in the present position of the history of the environment. We did not 
use any explicit means to calculate the value of that argument wrt. the initial 
position. But the magic of the definition of fbyLVS is that it only ever uses its 
first argument when the second has a history with no past (which corresponds 
to the situation when the present actually is the initial position in the history 
of the environment). So our most straightforward naive design gave exactly the 
solution that has been adopted by the dataflow languages community, probably 
for entirely different reasons. 

Notice also that we have obtained a generic comonads-inspired language de¬ 
sign which supports higher-order functions and the solution was dictated by 
the types. This is remarkable since dataflow languages are traditionally first- 
order and the question of the right meaning of higher-order dataflow has been 
considered controversial. The key idea of our solution can be read off from the 
interpretation of application: the present value of a function application is the 
present value of the function applied to the history of the argument. 

We can test the interpreter on the examples from Section [U The following 
examples make sense in both the general and causal stream function settings. 

— pos = 0 fby pos + 1 

pos = Rec (L "pos" (N 0 ‘Fby' (V "pos" :+ N 1))) 

— sum x = x + (0 fby sum x) 

sum = L "x" (Rec (L "sumx" (V "x" :+ (N 0 'Fby' V "sumx")))) 

— diff x = x - (0 fby x) 

diff = L "x" (V "x" (N 0 'Fby' V "x")) 

— ini x = x fby ini x 

ini = L "x" (Rec (L "inix" (V "x" 'Fby' V "inix"))) 

— fact = 1 fby (fact * (pos + 1)) 

fact = Rec (L "fact" (N 1 'Fby' (V "fact" :* (pos :+ N 1)))) 

— fibo = 0 fby (fibo + (1 fby fibo)) 

fibo = Rec (L "fibo" (N 0 'Fby' (V "fibo" :+ (N 1 'Fby' V "fibo")))) 
Testing gives expected results: 

> runLV (ev pos) emptyS 

0 :< (1 :< (2 :< (3 :< (4 :< (5 :< (6 :< (7 :< (8 :< (9 :< (10 :< ... 

> runLV (ev (sum :@ pos)) emptyS 

0 :< (1 :< (3 :< (6 :< (10 :< (15 :< (21 :< (28 :< (36 :< (45 :< ... 

> runLV (ev (diff :@ (sum pos))) emptyS 

0 :< (1 :< (2 :< (3 :< (4 :< (5 :< (6 :< (7 :< (8 :< (9 :< (10 :< ... 
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The ‘whenever’ operator and the sieve of Eratosthenes, which use anticipation, 
are only allowed with general stream functions. 

— x wvr y = if ini y then x fby (next x wvr next y) 

else (next x wvr next y) 
wvr = Rec (L "wvr" (L "x" (L "y" ( 

If (ini :(S V "y") 

(V "x" ‘Fby‘ (V "wvr" :8 (Next (V "x")) :fl (Next (V "y")))) 

(V "wvr" :@ (Next (V "x")) (Next (V "y"))))))) 

— sieve x = x fby sieve (x wvr x mod (ini x) /= 0) 
sieve = Rec (L "sieve" (L "x" ( 

V "x" ‘Fby‘ ( 

V "sieve" (wvr V "x" ( 

V "x" ‘Mod' (ini :fi (V "x")) :/= N 0)))))) 

— eratosthenes = sieve (pos + 2) 
eratosthenes = sieve (pos :+ N 2) 

Again, testing gives what one would like to get. 

> runLVS (ev eratosthenes) emptyS 

2 :< (3 :< (5 :< (7 :< (11 :< (13 :< (17 :< (19 :< (23 :< (29 :< ... 


6 Distributive Laws 

6.1 Distributive Laws: A Distributive Law for Causal Partial-Stream 
Functions 

While the comonadic approach is quite powerful, there are natural notions of 
impure computation that it does not cover. One example is clocked dataflow or 
partial-stream based computation. The idea of clocked dataflow is that different 
signals may be on different clocks. Clocked dataflow signals can be represented 
by partial streams. A partial stream is a stream that may have empty positions 
to indicate the pace of the clock of a signal wrt. the base clock. The idea is to 
get rid of the different clocks by aligning all signals wrt. the base clock. 

A very good news is that although comonads alone do not cover clocked 
dataflow computation, a solution is still close at hand. General and causal partial- 
stream functions turn out to be describable in terms of distributive combinations 
of a comonad and a monad considered, e.g., in |8I33| . For reasons of space, we will 
only discuss causal partial-stream functions as more relevant. General partial- 
stream functions are handled completely analogously. 

Given a comonad (D, e— t) and a monad (T, rj, —*) on a category C, a distribu¬ 
tive law of the former over the latter is a natural transformation A with compo¬ 
nents DTA —y TDA subject to four coherence conditions. A distributive law of 
D over T defines a category Cn.r where \Cd,t\ = \C\, Cd,t{A, B) = C{DA, TB), 
(idr),r)A = ?m°£a, £° D , T k = l* o \ B otf for k : DA — ► TB, i : DB — > TC (call 
it the biKleisli category), with inclusions to it from both the coKleisli category 
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of D and Kleisli category of T. If the monad T is strong, the biKleisli category 
is a Freyd category. 

In Haskell, the distributive combination is implemented as follows. 

class (ComonadZip d. Monad t) => Dist d t where 
dist : : d (t a) -> t (d a) 

newtype BiKleisli d t a b = BiKleisli (d a -> t b) 

instance Dist d t => Arrow (BiKleisli d t) where 
pure f = BiKleisli (return . f . counit) 

BiKleisli k »> BiKleisli 1 = BiKleisli ((»= 1) . dist . cobind k) 
first (BiKleisli k) = BiKleisli (\ d -> 

k (cmap fst d) »= \ b -> 
return (b, snd (counit d))) 

The simplest examples of distributive laws are the distributivity of the identity 
comonad over any monad and the distributivity of any comonad over the identity 
monad. 

instance Monad t => Dist Id t where 
dist (Id c) = mmap Id c 

instance ComonadZip d => Dist d Id where 
dist d = Id (cmap unld d) 

A more interesting example is the distributive law of the product comonad over 
the maybe monad. 

instance Dist Prod Maybe where 
dist (Nothing :& _) = Nothing 
dist (Just a :& e) = Just (a :& e) 

For causal partial-stream functions, it is appropriate to combine the causal 
stream functions comonad LV with the maybe monad. And this is possible, since 
there is a distributive law which takes a partial list and a partial value (the past 
and present of the signal according to the base clock) and, depending on whether 
the partial value is undefined or defined, gives back the undefined list-value pair 
(the present time does not exist according to the signal’s own clock) or a defined 
list-value pair, where the list is obtained from the partial list by leaving out 
its undefined elements (the past and present of the signal according to its own 
clock). In Haskell, this distributive law is coded as follows. 

filterL :: List (Maybe a) -> List a 
filterL Nil = Nil 

filterL (az :> Nothing) = filterL az 
filterL (az :> Just a) = filterL az :> a 

instance Dist LV Maybe where 
dist (az := Nothing) = Nothing 
dist (az := Just a) = Just (filterL az := a) 



The Essence of Dataflow Programming 161 


The biKleisli arrows of the distributive law are interpreted as partial-stream 
functions as follows. 

runLVM :: (LV a -> Maybe b) -> Stream (Maybe a) -> Stream (Maybe b) 
runLVM k (a’ :< as’) = runLVM’ k Nil a’ as’ 

where runLVM’ k az Nothing (a’ :< as’) 

= Nothing :< runLVM’ k az a’ as’ 

runLVM’ k az (Just a) (a’ :< as’) 

= k (az := a) :< runLVM’ k (az :> a) a’ as’ 


6.2 Distributivity-Based Semantics 

Just as with comonads, we demonstrate distributive laws in action by present¬ 
ing an interpreter. This time this is an interpreter of languages featuring both 
context-dependence and effects. 

As previously, our first step is to fix the syntax of the object language, 

type Var = String 

data Tm = V Var I L Var Tm I Tm Tm I Rec Tm 

I N Integer I Tm :+ Tm I ... 

I Tm : == Tm | ... I TT I FF I Not Tm I ... I If Tm Tm Tm 

— specific for causal stream functions 

I Tm ‘Fby‘ Tm 

— specific for partiality 
I Nosig | Tm ‘Merge' Tm 

In the partiality part, Nosig corresponds to a nowhere defined stream, i.e., a 
signal on an infinitely slow clock. The function of Merge is to combine two 
partial streams into one which is defined wherever at least one of the given 
partial streams is defined. 

The semantic domains and environments are defined as before, except that 
functions are now biKleisli functions, i.e., they take contextually situated values 
to values with an effect. 

data Val d t = I Integer I B Bool I F (d (Val d t) -> t (Val d t)) 
type Env d t = [(Var, Val d t)] 

Evaluation sends terms to biKleisli arrows; closed terms are interpreted in the 
empty environment placed into a context of interest. 

class Dist d t => DistEv d t where 

ev :: Tm -> d (Env d t) -> t (Val d t) 

evClosedLV :: DistEv LV t => Tm -> Int -> t (Val LV t) 
evClosedLV e i = ev e (emptyL i := empty) 

The meanings of the core constructs are essentially dictated by the types. 
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_ev :: DistEv d t => Tm -> d (Env d t) -> t (Val d t) 

_ev (V x) denv = return (unsafeLookup x (counit denv)) 

_ev (L x e) denv = return 

(F (\ d -> ev e (cmap repair (czip d denv)))) 
where repair (a, env) = update x a env 
_ev (e e’) denv = ev e denv »= \ (F f) -> 

dist (cobind (ev e’) denv) »= \ d -> 
f d 

_ev (Rec e) denv = ev e denv »= \ (F f) -> 

dist (cobind (_ev (Rec e)) denv) »= \ d -> 
f d 

_ev (N n) denv = return (I n) 

_ev (eO :+ el) denv = ev eO denv »= \ (I nO) -> 

ev el denv »= \ (I nl) -> 

return (I (nO + nl)) 

denv = return (B True ) 

denv = return (B False) 

denv = ev e denv »= \ (B b) -> 
return (B (not b)) 

1) denv = ev e denv »= \ (B b) -> 

if b then ev eO denv else ev el denv 

Similarly to the case with the monadic interpreter, the clause for of Rec in the 
above code this does not quite work, because recursive calls get evaluated too 
eagerly, but the situation can be remedied by introducing a type constructor 
class DistCheat of which LV with Maybe will be an instance. 

class Dist d t => DistCheat d t where 

cobindCheat :: (d a -> t b) -> (d a -> d (t b)) 

instance DistCheat LV Maybe where 

cobindCheat k d@(az := _) = cobindL k az := return (unjust (k d)) 
where cobindL k Nil = Nil 

cobindL k (az :> a) = cobindL k az :> k (az := a) 

Using the operation of the DistCheat class, the meaning of Rec can be redefined 
to yield a working solution. 

class DistCheat d t => DistEv d t where ... 

_ev (Rec e) denv = ev e denv »= \ (F f) -> 

dist (cobindCheat (_ev (Rec e)) denv) »= \ d-> 
f d 

The meanings of the constructs specific to the extension are also dictated by 
the types and here we can and must of course use the specific operations of the 
particular comonad and monad. 


_ev TT 
_ev FF 
_ev (Not e) 

_ev (If e eO 
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instance DistEv LV Maybe where 

ev (eO ‘Fby‘ el) denv = ev eO denv ‘fbyLV‘ cobind (ev el) denv 
ev Nosig denv = raise 

ev (eO ‘Merge* el) denv = ev eO denv ‘handle' ev el denv 

The partial, causal version of the sieve of Eratosthenes from Section [5] is 
defined as follows. 

— sieve x = if (tt fby ff) then x 

else sieve (if (x mod ini x /= 0) then x else nosig) 
sieve = Rec (L "sieve" (L "x" ( 

If (TT ‘Fby‘ FF) 

(V "x") 

(V "sieve" 

(If ((V "x" ‘Mod' (ini V "x")) :/= N 0) 

(V "x") 

Nosig))))) 

— eratosthenes = sieve (pos + 2) 
eratosthenes = sieve (pos :+ N 2) 

Indeed, testing the above program, we get exactly what we would wish. 

> runLVM (ev eratosthenes) (cmap Just emptyS) 

Just 2 :< (Just 3 :< (Nothing :< (Just 5 :< (Nothing :< (Just 7 :< ( 
Nothing :< (Nothing :< (Nothing :< (Just 11 :< (Nothing :< (Just 13 :< ( 
Nothing :< (Nothing :< (Nothing :< (Just 17 :< ... 

7 Related Work 

Semantic studies of Lucid, Lustre and Lucid Synchrone-like languages are not 
many and concentrate largely on the so-called clock calculus for static well- 
clockedness checking |10I11I14) . Relevantly for us, however, Col ago et al- H3] have 
very recently proposed a higher-order synchronous dataflow language extending 
Lucid Synchrone, with two type constructors of function spaces. 

Hughes’s arrows [TO] have been picked up very well by the functional pro¬ 
gramming community (for overviews, see [30120) 1. There exists by now not only 
a de facto standardized arrow library in Haskell, but even specialized syntax 
[TO] . The main application is functional reactive programming with its special¬ 
izations to animation, robotics etc. [27118] . Functional reactive programming is 
of course the same as dataflow programming, except that it is done by functional 
programmers rather than the traditional dataflow languages community. The ex¬ 
act relationship between Hughes’s arrows and Power and Robinson’s symmetric 
premonoidal categories has been established recently by Jacobs and colleagues 
[21122) . 

Uses of comonads in semantics have been very few. Brookes and Geva [8] 
were the first to suggest to exploit comonads in semantics. They realized that, 
in order for the coKleisli category of a comonad to have exponential-like objects, 
the comonad has to come with a zip-like operation (they called it “merge”), but 
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did not formulate the axioms of a symmetric monoidal comonad. Kieburtz m 
made an attempt to draw the attention of functional programmers to comonads. 
Lewis et al. m must have contemplated employing the product comonad to 
handle implicit parameters (see the conclusion of their paper), but did not carry 
out the project. Comonads have also been used in the semantics of intuitionistic 
linear logic and modal logics m, with their applications in staged computation 
and elsewhere, see e.g., H5I , and to analyse structured recursion schemes, see e.g., 
[3912819] . In the semantics of intuitionistic linear and modal logics, comonads are 
strong symmetric monoidal. 

Our comonadic approach to stream-based programming is, to the best of our 
knowledge, entirely new. This is surprising, given how elementary it is. Workers 
in dataflow languages have produced a number of papers exploiting the final 
coalgebraic structure of streams [1212414] . but apparently nothing on stream 
functions and comonads. The same is true about works in universal coalge¬ 
bra |34I35| . 

8 Conclusions and Future Work 

We have shown that notions of dataflow computation can be structured by 
suitable comonads, thus reinforcing the old idea that one should be able to 
use comonads to structure notions of context-dependent computation. We have 
demonstrated that the approach is fruitful with generic comonadic and distribu- 
tivity-based interpreters that effectively suggest designs of dataflow languages. 
This is thanks to the rich structure present in comonads and distributive laws 
which essentially forces many design decisions (compare this to the much weaker 
structure in arrow types). Remarkably, the language designs that these inter¬ 
preters suggest either coincide with the designs known from the dataflow lan¬ 
guages literature or improve on them (when it comes to higher-orderness or to 
the choice of the primitive constructs in the case of clocked dataflow). For us, 
this is a solid proof of the true essence and structure of dataflow computation 
lying in comonads. 

For future work, we envisage the following directions, in each of which we 
have already taken the first steps. First, we wish to obtain a solid understand¬ 
ing of the mathematical properties of our comonadic and distributivity-based 
semantics. Second, we plan to look at guarded recursion schemes associated to 
the comonads for stream functions and at language designs based on correspond¬ 
ing constructs. Third, we plan to test our interpreters on other comonads (e.g., 
decorated tree types) and see if they yield useful computation paradigms and 
language designs. Fourth, we also intend to study the pragmatics of the combi¬ 
nation of two comonads via a distributive law. We believe that this will among 
other things explicate the underlying enabling structure of language designs such 
Multidimensional Lucid [3] where flows are multidimensional arrays. Fifth, the 
interpreters we have provided have been designed as reference specifications of 
language semantics. As implementations, they are grossly inefficient because of 
careless use of recursion, and we plan to investigate systematic efficient imple- 
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mentation of the languages they specify based on interpreter transformations. 

Sixth, we intend to take a close look at continuous-time event-based dataflow 

computation. 
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